1. Field of Invention
The present invention relates to distributed computing, and particularly to software tools for architecting and implementing distributed computing systems.
2. Description of Related Art
Software that sits between two or more types of software and translates information between them is generally referred to as “middleware.” Middleware covers a vast range of software and is typically situated between an application and an operating system, a network operating system, or a database management system. Examples of middleware include object-oriented programming code based on a Common Object Request Broker Architecture (CORBA™); software implemented according to a Distributed Computing Environment (DCE) industry-standard; JAVA™ Remote Method Invocation (JAVA™ RMI) programming code; and an application programming interface (API) based on ENTERPRISE JAVABEANS™ (EJB™). COBRA is a registered trademark of Object Management Group, Inc. JAVA™, ENTERPRISE JAVABEANS™ and EJB™, are registered trademarks of Sun Microsystems, Inc.
Middleware can serve as a tool that is employed to build distributed computing systems. For example, distributed computing middleware facilitates application components, i.e., programs, on different computers to talk to one another. One widely used technique for allowing one program to call a second program on a remote system is to implement remote procedure call (RPC) middleware. RPC middleware facilitates instructing a second program to perform a task requested by the first program and returning any results of that task to the first program.
One common method of developing distributed systems is to employ operating system APIs, or sockets API, for facilitating communications among distributed application components. Sockets API is an application programming interface, i.e., set of routines, to create and use sockets implemented by the operating system for client/server networking. A socket is an identifier for a particular service at a particular node on a network. Winsock, short for WINDOWS™ Sockets, is an API that provides a Transmission Control Protocol/Internet Protocol (TCP/IP) interface under MICROSOFT WINDOWS™, WINDOWS™ and MICROSOFT WINDOWS™ are registered trademarks of Microsoft Corporation.
FIG. 1 illustrates a conventional architecture 100 of a distributed application residing among two computing devices 110 and 120, and utilizing sockets API. In this example, the distributed application comprises of a first application component 112 residing on computing device 110 and a second application component 122 residing on computing device 120. Application components 112 and 122 are computer programs, or sets of instructions that a computer or other device executes to perform one or more actions. Computing devices 110 and 120 employ respective operating systems 114 or 124, and communicate with one another via network connection 130, implementation of which is apparent to one of ordinary skill in the art. Application components 112 and 122 are designed to utilize respective sockets API 116 or 126. Jagged lines illustrate that the API serves as an additional pseudo-software layer to interface adjacent software layers, e.g., application and operating system (OS) software layers in the present figure.
If application component 112 at computing device 110 wants to talk to application component 122 at computing device 120 via network connection 130, it first calls its operating system 114 through its sockets API 116. Operating system 114 then communicates via a communication protocol, typically TCP/IP, with operating system 124, which in turn calls application software 122 through its sockets API 126. If application component 122 wants to talk to application component 112, the reverse path/process is employed.
Sockets API is used for a variety of applications ranging from, for example, email systems to real time on-line gaming. In order to support such varied applications, sockets API must include many options and parameters, and allow for many different communication semantics. For instance, sockets API must support both connection oriented TCP semantics and connectionless User Datagram Protocol (UDP) semantics. All these options and parameters make the API complex. Considerable training and expertise is required in order for a programmer to use sockets API to implement systems that use the architecture of FIG. 1.
Distributed computing middleware manages inter-machine communication for the components of a distributed application and presents its own API. In essence, each application component of the distributed application talks to the middleware via a middleware API and the middleware then talks to the operating system often via sockets API. Middleware translates the information it carries from its own programming semantics to the programming semantics used by sockets API. Typically, the distributed computing middleware semantics are easier to use than those of sockets API. By using a simpler, more focused API, distributed computing projects can be completed quicker with higher quality by a smaller and less highly skilled team.
FIG. 2 illustrates a conventional architecture 200 of a typical distributed application residing among computing devices 110 and 120, and utilizing distributed computing middleware and sockets API. Particularly, application components 112 and 122 are designed to utilize respective middleware 212 or 214 residing at respective computing devices 110 or 120. Thus, a separate middleware layer is provided between the application and operating system layers. Middleware 212 or 222 each presents a middleware API 214 or 224 to respective application component 112 or 122. If application component 112 at computing device 110 wants to talk to application component 122 at computing device 120 via network connection 130, it first calls middleware 212 via the middleware API 214. After performing any necessary translation of the information being carried, middleware 212 in turn calls the operating system 114 through its socket API 116. Operating system 114 then communicates via TCP/IP with operating system 124, which in turn calls middleware 222 through its socket API 126. Middleware 222 then calls application component 122 through middleware API 224. If application component 122 wants to talk to application component 112, the reverse path/process is employed.
JAVA™ Message Service (JMS) is a standard API implemented by several distributed computing middleware vendors. JMS employs a publish/subscribe API for coordinating the efficient delivery of information. Publish/subscribe features topics, publishers, and subscribers. Conceptually, topics are pipes that carry messages. Publishers and subscribers are sets of instructions that put information into the pipe, i.e., topic, and take it out. Topics exist independently of publishers and subscribers, however all three are needed to make the communications information flow. In a distributed computing system, an application component can publish to a topic and/or subscribe to a topic.
A message published to a topic is delivered asynchronously to all the subscribers of the topic. JMS has its own message format featuring a header and a payload. The header comprises a set of name/value pairs, or header properties, some of which are defined by the publish/subscribe API and some defined by the application. Two header properties of particular importance are “message ID” and “correlation ID.” The message ID is a unique identification that is assigned by the middleware to every message it processes. When one message is related in some way to another, the application can set the correlation ID header property to equal the message ID of the related message. The payload is never examined by the middleware.
When a JMS publish/subscribe client subscribes to receive messages from a topic it specifies a message filter. The filter is a conditional expression that analyzes message header values. When a message is published on a topic it is delivered to every subscriber of the topic who's filter is satisfied by the messages header properties. For example, a chatroom application component might use a filter like this:                ((targetUser=‘phil’) OR (targetUser=‘all’)) AND (sendingUser NOT IN (‘darrell’, ‘jeff’))        
This filter would have the effect of allowing receipt of private messages directed to ‘phil’ or messages directed to the entire chatroom except when these messages were sent by the ignored users ‘darrell’ or ‘jeff’.
Request/reply programming is a cross between publish/subscribe and the very popular RPC model. With RPC as previously mentioned, a sender invokes a procedure on a remote application component and the remote component “returns” a response. Request/reply has several advantages over RPC. For example, request/reply supports the sending of messages to multiple receivers. Moreover, request/reply is asynchronous and is therefore better suited to situations where replies may take a long time to arrive or where the network, sender, or receiver may fail. Like publish/subscribe, but unlike RPC, request/reply communications can be conveniently attempted in situations where the existence, location, or number of receivers is not known by the sender. No conventional middleware directly supports simple request/reply semantics. Developers who wish to employ a request/reply design pattern must either do all their own communications programming utilizing sockets API as in FIG. 1 or use unsuitable middleware APIs. Such an implementation is complex and time consuming to design even for a highly skilled developer.